perm filename SKLEIN.3[RLL,DBL]1 blob
sn#648623 filedate 1982-03-19 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00012 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00003 00002 See all RLL.BBD[rdg,dbl],
C00004 00003 ∂TO SKLEIN@ISIB 13:25 8-Jan-82
C00010 00004 ∂11-Jan-82 1748 Steve Klein <SKLEIN at USC-ISIB> Re: Some comments
C00020 00005 ∂26-Jan-82 2013 Steve Klein <SKLEIN at USC-ISIB> awoof
C00021 00006 ∂08-Feb-82 1617 Steve Klein <SKLEIN at USC-ISIB> grmmph
C00022 00007 ∂TO sklein@isib 15:51 9-Feb-82
C00032 00008 ∂16-Feb-82 1415 Steve Klein <SKLEIN at USC-ISIB> postponement
C00033 00009 ∂TO skein@isib 18:01 17-Feb-82
C00034 00010 ∂TO SKLEIN@ISIB 16:47 1-Mar-82
C00038 00011 SNAFU
C00041 00012 ∂12-Mar-82 1530 Steve Klein <SKLEIN at USC-ISIB> NewKB problem
C00057 ENDMK
C⊗;
See all RLL.BBD[rdg,dbl],
also ARCHIVE.RLL[rdg,dbl] for backed-up information
(USERS.OLD had bunch of users,
SKLEIN.2 have old messages with Steve)
∂TO SKLEIN@ISIB 13:25 8-Jan-82
Some comments
Steve
(1) I realized this morning that the defn of *vaLue* is wrong.
The HighLevelDefn says to apply the MyLivesInSlot slot to the
value of (GetValue un 'MyLivesInUnit).
That's close: it should, however, apply the function stored on un:MyLivesInSlot
to that un:MyLivesInUnit value. As there is currently no direct mechanism for
doing that, we could define a function GetFromPointer,
which takes a unit, un, and returns (essentially)
(APPLY* (GetValue un 'MyLivesInSlot) (APPLY* (GetValue un 'MyLivesInUnit)))
The GetFromPointer unit would include some useful facts -- it rangetype should be
something like
(FSingleton (UnrestrictedType (*FromDomain GFP-Fn)))
where GFP-Fn would take a unit and return something like
'(*FromDomain *vaLue*Fn). [Or something like that -- see MapCross-Fn, or whatever.]
The idea is for *vaLue*:RangeType to be
(FSingleton (UnrestrictedType (*FromDomain *vaLue*Fn)))
where *vaLue*Fn takes a unit and returns the rangetype of the MyLivesInSlot of
that unit.
(2) Doug needs a brief, 1 page description of what's going on there - for some
report or other. It doesn't have to be prose, just enough for him to understand
what sort of things youse guys are doing, and why you are using RLL.
It might be interesting to see, in addition, your agenda of things needed,
and fixes made. (Basically for my edification...)
(3) Just a reminder: ComplexVV now calls (GetValue ? 'VerifyElement ...);
but should be calling a GetField - as the VerifyAll thing does.
(4) At some point I should send over the macro stuff I have up and running here;
and the next batch of LISP files. From there you could have the most updated
version.
(Until Rand and/or thesis stuff forces me back to hachery.)
(5) Some thoughts on EqualFormatSpec:
It would be a list, with each member of the form: (<format> <function>).
[That is, EqualFormatSpec:RangeType =
(FSet (FListN (UnitType (*P AnyFormat))
(FunctionType (*Range (FListN UnrestrictedType))))).]
If (fmt2 fn2) was included on fmt1:EqualFormatSpec, then
if some value, val, was acceptable to fmt2, then (fn2 val) will qualify as
an instance of fmt1. For example, FSet:EqualFormatSpec ==
( (FOrderedSet IDENTITY) ; Any ordered set is already a set
(FList MKSET) ; this removed duplicated elements
(FBag MKSET) ; (removes duplicated elements)
(FListN Scream) ; could be MKSET, but this is safer
(FSingleton LIST) ) ; ie this list qualifies*
*: actually the function FakeList should be used, where
(FakeList (v) (COND ((EQ v NoEntry) NoEntries) ((MustComputep v) v) (T (LIST v)))).
Given this, UnionDT and IntersectDT may be easier to (re)write, as well as
SubSpecFn for formats. Note it puts the facts (closer to) where they belong
-- on FSet, etc., rather than within a few functions.
Two final notes:
(i) Finding (fmt2 fn2) included on fmt1:EqualFormatSpec restricts the
fn1 in the (fmt1 fn1) included on fmt2:EqualFormatSpec. [Note it does not
completely define that fn1.]
(ii) Eventually it would be nice if EqualFormatSpec could be generated from
"first principles" -- looking on the various format's FormatCharacter.
----
That's all for now. Let me know how your work load dwindles, and whether/how
this RLL marrass(sp) works. I meandered over to ISIB last night, and found
the stuff we did unsaved! (or at least I couldn't find it).
Hope things are going ok,
Russ
∂11-Jan-82 1748 Steve Klein <SKLEIN at USC-ISIB> Re: Some comments
To: RDG at SU-AI
I'll look over the first 90% of your mss. later, but you are right on the last
point. I was on my way to the Consumer Electronics Show in Las Vegas just
after talking to you and managed to logout without saving the RLL image we
were working in. Good thing that the dribble file (presumably) still exists.
Murphy's law strikes again...
-------
∂13-Jan-82 1724 Steve Klein <SKLEIN at USC-ISIB> stufflets
To: RDG at SU-AI
Accumulation of small things:
∂TO sklein@isib 20:28 13-Jan-82
Possible answers
**** My comments are interspersed. enjoy...
1. for Range restrictions, the original solution you wrote up talks of
checking u:MyLivesInUnit 's SuperTypEx's for superspecs. However,
this only works for CLASS restrictions. If the RangeType spec is found
on a subunit for an INSTANCE, then it has no TypicalExampleOf slot and
hence no SuperTypEx's.
**** Q: Have you a scenario in which this occurs? As you noted, the only
place where a restriction currently makes sense is for classes --
basically because I didn't see any other place where a restriction
might occur...
HOWEVER, the concept seems still valid, since
it has some superior TypicalExamples. What do you think of changing
the defn of SuperTypEx (and rest of group) from
(Composition TypicalExample SuperClass TypicalExampleOf) to
(Composition TypicalExample SuperClass Isa) ?
**** Hmmm - Independent of the first point above, this might still
be a good idea. (Given that TypicalExampleOf is (essentially) a subslot
of Isa (I think). The question again is, is this needed? This will
make the computation of SuperTypEx (potentially) more expensive, if one
day we formally make Isa a complex slot. When will you want a SuperTypEx
of a non-typicalexample? (Beyond that possible case of restricting
from an instance.)
2. I'm tentatively calling the slot you named SuperSpecFn
FnForVerifyingRangeRestriction (unless you have an objection).
**** Sure - it's you who'll have to type that Moby-name.
But I think it does convey the correct idea.
3. Following convention, the fn on RangeTypeOfTypicalSubUnit:VerifyAll
seems to look like (LAMBDA (un sl val ...]. Is it the case that the
sl parm is ALWAYS RangeType for this fn?
**** Sorry - "sl parm"? Please explain.
4. Is the other parm for *vaLue*:ToCompute that you were speaking of
-COMPUTE or something else?
**** Yes (to the disjunct), it was something else: IGNORE-CACHE.
So the call should be something like
(PROG ((u (GetValue un 'MyLivesInUnit '(SAFESLOT)))
(s (GetValue un 'MyLivesInSlot '(SAFESLOT))))
(RETURN (GetValue u s `(SAFESLOT (-CACHE (,u ,s)) (IGNORE-CACHE (,u ,s))))))
[which, unless the "s" slot is exceptional, is about the same as
(UnitFnGV (GetValue un 'MyLivesInUnit '(SAFESLOT))
(GetValue un 'MyLivesInSlot '(SAFESLOT))
'(SAFESLOT)),
sorta]
The idea is to IGNORE the value stored in u:s -- that will be the
(*Do* FSeeUnit sOfu), which, if investigated, will lead to an infinite
recursion. Note we don't want to store this computed value on u:s -- instead
it will be up to *vaLue*:ToCacheValue to decide what to do with this.
Maybe this function could meander about, and caching the value only if
s:ToCacheValue said to do so. (ie something like
(LAMBDA (uN sL vAL ...) (* Note sL = *vaLue*, and uN is a subunit.)
(APPLY* (GetValue (GetValue uN 'MyLivesInSlot) 'ToCacheValue)
uN sL vAL ...))
5. If each of the FnForVerifyingRangeRestriction fns takes only a pair
of specs and the "loop" is done in RangeTypeOfTypicalSubUnit:VerifyAll,
things seem to look simpler. See anything wrong with this?
**** I think not - but perhaps I'm just confused. Could you spell out
your proposal. (It sound like you think you're going to keep hitting
RangeTypeOfTypicalSubUnit:VerifyAll, which is NOT the case.)
6. If I actually use the EqualFormatSpec approach instead of punting when
there isn't a match, exactly what should be done? The information
that is encapsulated in the transformation function doesn't help
in verifying that two specs are equivalent (at least to me). I wouldn't
necessarily think that you would want to actually do the transformation
and see what results as a way of telling whether it is legal...
Also not clear whether some mapping of the sub-specs needs to be done
DEPENDENT upon the particular mapping at this un-equal level...
Any enlightenment?
**** Depends on what you consider to be a legitimate subrange. I, for example,
feel queasy at the prospect of letting something of format FSingleton be a
restriction of a FSet format -- but you indicated this is acceptable.
Possibility one: only include fmt2 on fmt1:EqualFormatSpec if it is a legal
restriction -- this makes the task trivial -- just use ASSOC.
If you want to include other formats, then you may have to do something like
include another field - indicating its acceptability as a restriction;
or possibly here's a place when your could use the FormatCharacter slot directly,
(avoiding this EqualFormatSpec altogether): by indicating which of the
characteristics must be the same, or how different. Yes, 'twould be a bag of
worms, but might be worthwhile in the long run.
-------
Hi. Any additions to the following list of fns to be recorded when
called from LISPX level?
AddField AddValue
DeleteField
KillField KillValue
PutField PutValue
SubstField SubstValue
UA-PUT
**** Why this one? (/\)
UA-PUTPROP
[remember to twiddle EDITU to use this \fn.]
I think I'll assume all changes are written to a single file and a filter
predicate will be applied at load time to pick the ones to be executed.
**** Yes, this makes sense.
How will you address the case of when a function breaks?
Otherwise there is no (reasonable) way to keep the sequencing straight
between the calls that would appear on several files.
-------
**** Russ
∂13-Jan-82 1912 Steve Klein <SKLEIN at USC-ISIB> recording changes
To: RDG at SU-AI
∂26-Jan-82 2013 Steve Klein <SKLEIN at USC-ISIB> awoof
Hi. Typically, I got diverted onto other matters again. Got your
example (TypicalShip stuff) through almost to completion, so I suppose
that about 95% of the "task" is done...should be easy to then test our
first example (the time units). Several questions, of course, came up.
I should be back on track and have things "proved" near the end of the
week--get back to you then to go over the results, etc. Enjoy.
-------
∂08-Feb-82 1617 Steve Klein <SKLEIN at USC-ISIB> grmmph
The bug where accessing a unit causes an end of file error has reappeared.
Since this is extremely irritating, I'm going to see if I can pin down what
is happening. However, I need the CORLL sources to do so and can't find or
don't have access to them from RAND or SCORE...help.
-------
∂TO sklein@isib 15:51 9-Feb-82
A penny for...
Steve -
Finally got a chance to write down my thoughts - for what they're worth.
Working thru this example, the top call was
Goal 1:
GetValue(Ship#47 Cost),
(where Cost:Isa = AnyComplexSlot).
As no value was stored on the Cost slot of the Ship#47 unit, Cost:ToCompute
was called, which would compute this value.
Goal 2:
GetValue(Cost ToCompute)
had to be computed as well, which required ...
This ended up being inherited from TypicalComplexSlot:ToCompute, which,
if memory serves, basically calls
Goal 3:
GetField(Ship#47 Cost ToCompute).
Not finding a CostOfShip#47 subunit, this calls
GetValue(ToCompute ToComputeField),
handing it Ship#47 and Cost.
(Is this right? I don't think its ToComputeField(Cost)...)
Anyway, that TC:TCF function is an OR junction of a MapUntilOk and a
GetValue.
Note in this case, we'd like the MapUntilOk to return NIL, letting
the TC:TCF function return the value of
GetValue(Cost ToCompute) -- which is what should happen.
(That is, the result of Goal 3 is Cost:ToCompute.)
But back to the plot:
Let ops <= Ship#47:OrderedPrototypes. The MapUntilOk takes each op-i IN ops,
and asks for (GetField op-i 'Cost 'ToCompute '(-CreateSubUnit...)).
In our case, we'd like each such GetField to return an nonOK value,
permitting the overall MapUntilOk to return NIL.
If there is no op-i:Cost subunit, Cost:ToComputeField is called, which does
the correct thing -- with the -CreateSubUnit value in the "other" arg, this
will return NIL, as desired.
The problem is when there is such a subunit. The first such case is for
CostOfTypicalShip. Here GetField(TypicalShip Cost ToCompute) reduces to
GetValue(CostOfTypicalShip ToCompute).
This is appropriate -- if there was a value primitively stored, we'd want that
used. Otherwise there may be a HighLevelDefn associated with CostOfTypicalShip,
from which we could compute that ToCompute value.
In this case, there is no primitive CostOfTypicalShip:ToCompute, nor is there
a CostOfTypicalShip:HighLevelDefn. Now FunctionSpec:ToCompute (or maybe
the derived FunctionSpec:LispFn) tells us to check the
Orderedprototypes of the unit (here CostOfTypicalShip),
seaching for a default value.
CostOfTypicalShip:Orderedprototypes includes TypicalSubUnit, and then
some even more irrelevant units -- TyppcalAbstractThing and TypicalThing.
Currently none of the three units has a ToCompute slot -- note that ToCompute
isn't even defined for the latter two units.
Some notes: (1) The GetAccessFn included in FunctionSpec:ToCompute
insists that a value be found here -- it gives the warning message now found.
(I think -- I'm not quite sure of this.)
(2) Part of me wants to make AnySubUnit a subclass of AnySlot -- in which class
the TypicalSlot:ToCompute value will be found, saving the day. But the rest
of me conceeds that this would be a great step backwards... Sigh.
There are several things which could be done.
(i) Don't use GetAccessFn in FunctionSpec:ToCompute.
Use instead a related, but less complaining function -- one which tolerates
not finding a value. Then the caching part of this FS:TC will have to
be a bit smarter. (Given that this isN'T the suggestion I'm backing, I'll
not elaborate.)
(ii) Store some new constant on TypicalSubUnit:ToCompute, effectively meaning
stop looking, and return me. (Proposed name: NothingHereOrAbove.)
This value will be returned by MapUntilOk. Note we still want the OR
to ignore this answer, requiring a new predicate IsOk&Significant
(which is (LAMBDA (x) (AND (IsOk x) (NEQ x NothingHereOrAbove) x)).
This would go around the MapUntilOk.
Problems: should this value be cached on TypicalShip:ToCompute?
How should this be added to TypicalSubUnit -- given that it is not the function
which ToCompute:RangeType expects. Should FSingleton, and friends, know about
this new constant? Do we really need it? ... what a mess ...
(iii) Perhaps the value of CostOfTypicalShip:ToCompute should be something like
(*Do* FSeeU&S Cost ToCompute)? Working backwards, this may imply that
TypicalSubUnit:ToCompute be something like
(*Do* FExecute (LAMBDA (u s o) (* Here u is, eg, CostOfTypicalShip)
`(*Do* FSeeU&S , (GetValue u 'MyLivesInSlot) ToCompute))).
This seems hacky -- especially when the time comes to cache this value of
CostOfTypicalShip:ToCompute.
(iv) and now for the real proposal: Store something like
(*Do* FExecute (LAMBDA (u s o)
(GetValue (GetValue u 'MyLivesInSlot) 'ToCompute)))
This will compute, here, Cost:ToCompute. This value may then be cached away --
depending on the function associated with Cost:ToCacheValue (which will probably
be whatever is found on TypicalComplexSlot:ToCacheValue).
NOTE: this eliminates the need for that top OR in TC:TCF, at least in this
case.
I recommend leaving the OR in, for now at least, as other things may use
this TC:TCF function (ie if this is the function stored on TypicalSlot:TCF).
----
Finally, realize the same types of things must be done for
RangeType and DomainType as they're computed with ToCompute. (Ie this sort
of *DO* must be placed on those slots of TypicalSubUnit.)
----
Anyway, once this done, that Goal 3
[GetField(Ship#47 Cost ToCompute)] will return the correct value
[that is, the value of GetValue(Cost ToCompute)].
That will do the right thing -- satisfying Goal 2 and then Goal 1,
(i hope).
Sound good?
I'm not really happy about soln (iv) if it forces us to but something like
that messy *DO* clause on each slot on TypicalSubUnit. Perhaps we could
circumvent that problem by talking about a particular class of slots, which
"terminate" on TypicalSubUnit with this sort of value...
Perhaps we should use that variable approach to cache some special value
on each TypicalXXX:YYY, whenever TypicalXXX is on YYY:MakesSenseFor -- to
shorten the othrwise duplicated long search.
More later. Let me first mail this off, and await critiques. Then we
can pursue patches to other RLL problems, and then, finally, address some of
these even more time-consuming issues.
Russ
By the way, Ben says Hi.
∂16-Feb-82 1415 Steve Klein <SKLEIN at USC-ISIB> postponement
Hi. Things have gotten hectic again...mind if I delay a continuation of our
conversation for a couple of days?
Steve.
-------
No problem.
∂TO skein@isib 18:01 17-Feb-82
Quicky
Steve
I just realized I never had youse guys fill out a "non-disclosure
agreement" prior to using RLL.
So I'm now snail mailing a copy of that form, which I guess
you and Bill Mann should sign and send back. (who knows why?)
Russ
∂TO SKLEIN@ISIB 16:47 1-Mar-82
Re: MAPHASH problems in Interlisp??
Steve:
I just received this message -- I'm not quite sure why.
However, it might be relevant...
How are things going, anyway?
Russ
----
∂01-Mar-82 1554 Masinter at PARC-MAXC Re: MAPHASH problems in Interlisp??
In-reply-to: KINI's message of 23 Feb 1982 1604-PST
To: Vittal Kini <KINI at USC-ISIB>
cc: InterlispSites↑
(I'm cc:ing InterlispSites↑ on the response because this problem is not widely
known.)
Vittal:
(1) You have unfortunately run into one of the more subtle problems with
MAPHASH in Interlisp-10: if a garbage collection which MOVES STORAGE
occurs during the middle of a MAPHASH, it is possible for the hash
pointers to move around, and for entries to be missed and for some entries
to be visitied twice. This is the only situation in which MAPHASH will
omit items or present them twice (note that "rehashing" actually copies the
original array into another one, so that if a rehash occurs because of overflow,
you may get outdated information but not any duplicates.)
(2) The problem is that if a reclaim needs to increase the size of one of the
contiguous areas (such as array space or string pointer space), it may actually
move around pages of atoms. It isn't that atoms get compacted but rather that
other spaces have to increase which causes the atoms to get moved around.
(3) The way that I worked around this problem when I ran into it was
(a) MAPHASH down the array, collecting a list of the "keys"
(b) MAPC down that list, performing the operation
This guarantees that no string/array/pname garbage collection will occur during
MAPHASH.
There are some proposals for fixing this problem in Interlisp-10 (e.g., marking the
array that it is being maphashed, and if so marked, not rehashing during a
reclaim but fixing it the next puthash) but so far (for the last 4 years) no
progress on fixing it.
This bug is not present in other Interlisp implementations, as far as I know.
Larry
SNAFU
Steve -
SCORE went down just after you linked. I then tried to tell you
this, via SAIL, which was, you guessed it, down.
Anyway, what were you about to say?
Russ
∂TO sklein@isib 13:47 5-Mar
∂05-Mar-82 1341 Steve Klein <SKLEIN at USC-ISIB> Re: SNAFU
I was (and still am) in the process of gathering up the set of questions/
function changes outstanding, etc... Slightly sidetracked (again) on day-to-day
bug fixes, so what's your schedule rest of today? ...Ok to give you a call
about 5:00?
-------
[rdg] Unfortunately no -- I'm expecting a call about then, to finalize plans
about activities scheduled for this evening.
I have to run some errands about campus today -- probably consuming from
2-3. Calling anytime from 3 until 4:30 today is ok, as is anytime before
5:45PM on Saturday.
Sunday noon I'm leaving for a(n) HPP retreat, in Asilomar.
We'll return ca 5PM Tuesday.
∂05-Mar-82 1352 Steve Klein <SKLEIN at USC-ISIB> Re: ∂05-Mar-82 1341 Steve Klein <SKLEIN at USC-ISIB> Re: SNAFU
I'll aim for 3-3:30...
-------
∂05-Mar-82 1538 Steve Klein <SKLEIN at USC-ISIB> sigh...
Hi.
Looks like I won't get back to this part of the world again until Monday...
Probably best to further process the open questions and go over them
Wednesday after your're decompressed. Enjoy the intensity.
Steve.
-------
∂TO sklein@isib 15:41 5-Mar
psi...
Ok, will hear from you Wednesday.
Feel free to send some hints/overviews of your suggestions/modifications/...;
and thereby give me a chance to begin digesting them.
Or not, as you wish.
Enjoy
Russ
∂12-Mar-82 1530 Steve Klein <SKLEIN at USC-ISIB> NewKB problem
This is a recurrence of the problem I couldn't document before. If I make
a new KB, get into stack overflow. Analysis yields the loop of
GetValue(NumOpens Format) -->
GetValue(NumOpens RangeType) -->
GetValue(NumOpens FunctionSpec) -->
GetValue(NumOpens ToCompute
((-CACHE FunctionSpec)(From NumOpens FunctionSpec))) -->
GetValue(NumOpens Format) ...
Standard problem, except why coming up now, and due to the strange way of
problem occuring, the additional stuff on ToCompute gets lost, so the normal
halt doesn't happen... Familiar?
-------
Hmmm - yes, this is familiar, damnit. Let me look over your shoulder over at ISIB.
∂TO sklein@isib 13:42 13-Mar
A suggestion, or two
Steve -
Have you tried doing a GAINSPACE (or RECLAIM) when after a
stack overflow occurs? Perhaps that will free up the released stack
frames...
Also, I looked thru my various TODO files, or misc machines -- to
see if I ever recorded the fix to NumOpens, and whatever else. Alas,
I (too) hadn't. Sorry. Were you able to fix the problem?
(Damn these flakey systems anyway. If only my finger of accusation wasn't
directed back at me.)
Any other problems encountered (yes, that was rhetoric)?
Russ
∂15-Mar-82 1946 Steve Klein <SKLEIN at USC-ISIB> bug-debug
Here is my analysis of the bug caused by NumOpens not having a HLD or RangeType:
--> comes from TypicalPrimitiveSlot:ToCompute =
(*Do* FExecute (LAMBDA (un sl ot)
`(LAMBDA (unt oth)
,(EmptyValue un) ) ) )
*** Notice that the call to EmptyValue doesn't pass the Other info.
Since EmptyValue finally calls (GetValue un 'Format '(SAFESLOT)), if
the Primitive Slot that started this whole search was Format, we have
come full circle.
*** General Observation: Functions that contain embedded GetValue (or kin)
calls AND don't take other-type advice had better be extremely sure
that those calls can't be a source of trouble.
I'm not sure whether the viewpoint here should be that we should always be
able to find the format of a primitive slot, or that EmptyValue should take
Other-type stuff (here, easily passed down in TypicalPrimitiveSlot:ToCompute).
I await your clarifying missive...
-------
∂TO sklein@isib 12:00 16-Mar
Good sleuthing!
Yes, EmptyValue should take an additional arg, and merge that with SAFESLOT
on its call to GetValue. ...and yes, this is points to a general improvement to
the system -- essentially ALL calls to GetValue should have that additional
argument, passed to it from above.
Of course this makes things like EmptyVaue take longer in general. One solution
would involve MACROizing EmptyValue -- and when the additional argument is NIL,
not bothering with the AddOnChar function. This sort of trick might work in
general.
Final note: I checked the Dec/81 version of UTIL on Rand-Ai -- sure enough
EmptyValue was just changed to take that additional arg! So I'm consistent,
if forgetful
Suggestion: you might FTP over the versions of RLL.., UTIL.., etc from Rand-Ai,
and just see what sorts of things I'd twiddled way back when. Of course
all of these changes will be merged in after your changes have been added;
but who knows what other problems await which have already been (clandestinely)
solved...
Sorry about all of this tedious, meaningless overhead. Certainly it'll be
over soon. (By the way, I have this nice bridge I've been trying to sell
for a while...)
Russ
∂16-Mar-82 1224 Steve Klein <SKLEIN at USC-ISIB> Re: Good sleuthing!
I presume you also altered FormatIsList? to take the additional arg too. Since
this problem is (hopefully) solved by giving NumOpens a RangeType, I'll ignore
fixing the functions. Be interesting to see what other stuff is different, but
I think I'll wait for the next "release"...up to generating one when I ship back
my set of changes?
-------
--
∂TO sklein@isib 13:10 16-mar
Catches, drops and releases
Actually, I didn't correct "FormatIsList?" -- thanks for catching it.
Any others that you know about?
What will be involved with generating the next release? Simply merging a few
LISP code files? Will you have all the needed unit modifications in the
RecordKBChange file? and so you'll actually produce the desired new set
of units?
The only other change I know about is with the (X)UTIL files -- Dave's been
twiddling them to accomodate InterLisp-D on th Dolphin. I'll bring those
over to Rand-Ai eventually -- should I cart them to ISIB as well?
Is there anything else to do (besides wait for everything to collapse when
all of these modifications conflict with each other in the worst possible
ways...)?
Before I forget: had I mentioned my vacation plans? I'll be on the east coast
during 21-26 March, visiting NY and then Boston -- and hence, for the most part,
unavailable. Just thought I'd warn you ahead of time.
What plans have you?
Russ
∂16-Mar-82 1338 Steve Klein <SKLEIN at USC-ISIB> Re: Catches, drops and releases
I only mentioned FormatIsList? since it is the one that does the GetValue,
and hence really needs the advice, but wasn't passed it by EmptyValue.
My (current) notion of the next release cycle involves two operations.
One is merging of lisp code, both fixes and the recording stuff.
Second is merging of kb changes. Since you have made changes which aren't
recorded anywhere, presumably, the best thing to do is merge my changes into
your kbs. I'm willing to let you do that or to merge the changes myself
after grabbing the latest versions you have...presumably this latter move
would either require that you get back a set as the new base, or declare
the set here as the base (not clear there is any advantage to that).
I suppose where the most up-to-date stuff sits decides a lot of this.
Another interesting problem is how to record creation of new units. Offhand
suggestion involves calling the recording stuff directly from the functions
involved--NU, NewUnit, NewTypEx, etc... presumably a UA-PUT would end up
on the changes file... Any comments?
-------
---
∂TO sklein@isib 13:55 16-Mar
<blah>
Hmmm -- so how could I have gotten by fixing only EmptyValue?
...just one of those things I guess...
I'm neutral as to who actually plays watchdog durig the merging --
leaning towards letting you do it, purely thru laziness. Whoever does
it should clearly keep a full dribblefile of the goings-on, both for
posterity and for the other party.
I guess I'd like to let the official version sit of Rand-Ai -- that way
I can justify keeping my account there, and also I'll be able to use a different
version if and when I do any more hacking this lifetime.
Unit creation does indeed present a mess.
I think the only option is to "advise" the (top level calls to) NU, NewIsa, ...
[I almost suggested advising FNewUnit, which I think they all call,
(possibly excluding NU,) when I realized this wasn't quite right:
if that call is embedded, we do NOT wat it included, as the calling
function should be recorded, and that should be sufficient.
Note this means there should be a \NewKB...]
Its not quite clear what should happen here. Perhaps a UA-SETPROPLIST
should be recorded, corresponding to just before the call to EDITU.
The subsequent edits would be recorded appropriately.
Note the "additional value" to (\)PutValue
(telling it this is a new unit, to be handled accordingly)
is already done by EDITU.
Will this work; I've a gut level feeling I left out some important sub-case?
Russ
∂18-Mar-82 1716 Steve Klein <SKLEIN at USC-ISIB> NewZZZZZZZZ
To: RDG at SU-AI
Hi. Anuzer complication. Since NewIsa, NewSubClass, ... don't HAVE to
have all their inputs specified, they cannot be advised in the normal way
(to record their call). The most reasonable solution (pending your insight)
seems to be either give in and modify their definitions to call the /PutValue
type functions directly, or modify their definitions to do the recording call
after all the parameters have been specified. The unstated options are to
disallow calls with unspecified parameters or to record the calls "as-is" and
hence sometimes wrong. A nicer thing, of course, would be for lisp to
DIRECTLY support parameter defaults, parameter request/completion, and
advice coming either before or after the above were utilized. Dream on...
I don't feel that motivated (or stupid). I seem to recall that some other
dialects do this correctly...
Steve.
-------
∂TO sklein@isib 15:18 19-Mar
Oh yeah...
good point. Fortunately I think we can asssme that NewIsa and friends will
always be called from top level -- unless the user wants the interaction,
he is better off calling FNewUnit. So here's the suggestion:
Move NewIsa, NewSubClass, ... to \NewIsa, \NewSubClass, ...,
which will hence forth be the top level versions of the functions (using
the appropriate LISPXwhatever).
Then change NewIsa, NewSubClass ... to simply return an error message and die.
This will prevent anyone from calling NewIsa inside a function...
Realize this means every call to NewUnit should be recorded, and this,
in turn, leads to an easy fix:
Have NewUnit call \FNewUnit, which does all the right things -- ie records
all of its arguments.
There are still hassles when the user changes this neo-natal unit in the
EDITU call, but I addressed that in my last message. Did that
comment make sense?
I, too, feel there should be some better way of doing this... but couldn't
generate it.
Everything else there work? Anything else?
Russ